1. Field of the Invention
The invention relates generally to automatic power control and more particularly to remote control methods and devices to maintain computer network system availability.
2. Description of the Prior Art
Enterprise networks exist to support large world-wide organizations and depend on a combination of technologies, e.g., data communications, inter-networking equipment (frame relay controllers, asynchronous transfer mode (ATM) switches, routers, integrated services digital network (ISDN) controllers, application servers), and network management application software. Such enterprise networks can be used to support a large company's branch offices throughout the world, and, as such, these networks have become mission critical to the functioning of such organizations. Masses of information are routinely expected to be exchanged, and such information exchanges are necessary to carry on the daily business of modern organizations. For example, some international banks have thousands of branch offices placed throughout Europe, Asia and the United States that each critically depend on their ability to communicate banking transactions quickly and efficiently with one another and headquarters.
A typical enterprise network uses building blocks of router and frame relay inter-networking devices mounted in equipment racks. Such equipment racks are distributed to remote point of presence (POP) locations in the particular network. Each equipment rack can include frame relay controllers, routers, ISDN controllers, servers and modems, etc., each of which are connected to one or more power sources. The value of POP equipment can range from $200,000 to $500,000, and the number of individual devices can exceed a thousand.
Many enterprises rely on an uninterruptable power supply (UPS) to keep their inter-networking devices operational. Many inter-networking devices are typically connected to a single UPS, and this sets up a problem. When an individual router locks up, the router's power cannot be individually cycled on and off externally at the UPS because it is connected to a multiple power outlet. The recovery action choices available to the network control center operator thus do not include being able to reinitialize the individual equipment through a power interruption reset. The network operator could command the UPS to power cycle, but that would reset all the other attached devices that were ostensibly operating normally and carrying other network traffic. Another option is to dispatch someone to the remote location to reset the locked-up device. Neither choice is an attractive solution.
In large organizations that have come to depend heavily on enterprise networks, great pressures develop to control costs and thus to improve profits. Organizational down-sizing has been used throughout the corporate world to reduce non-network costs, and that usually translates to fewer technical people available in the right places to support large and complex in-house global networks. Such reduced repair staffs now rely on a combination of centralized network management tools and third-party maintenance organizations to service their remote POP sites. The costs associated with dispatching third-party maintenance technicians is very high, and the dispatch and travel delay times can humble the business operations over a wide area for what seems an eternity.
Global communication network operators, located at a few centralized network management centers, are relying more and more on automated network management applications to analyze, process, display and support their networks. An increasing number of network management software applications are being marketed that use open-system standardized protocols. Particular network application tool software is available to report lists of the inter-networking devices, by location, and can issue trouble lists and keep track of software versions and releases. New simple network management protocol (SNMP) applications are conventionally used to issue alarms to central management consoles when remote inter-networking devices fail.
One such SNMP network management application is marketed by Hewlett-Packard. HP OPENVIEW is a family of network and system management tools and services for local and wide area multivendor networks. OPENVIEW is a management platform that provides application developers and users with the ability to manage multivendor networks and expand their distributed computing environments. OPENVIEW allows network operation centers to build an intelligent hierarchical network management application, and uses open standards such as SNMP, user datagram protocol (UDP), and the now ubiquitous transmission control protocol/internet protocol (TCP/IP). Because OPENVIEW is built on open system standards, global communication network operators can easily integrate the various inter-networking equipment nodes into a managed environment operated by strategically located network consoles.
In order to provide a reliable computing environment, a robust and active process for problem resolution must be in place. OPENVIEW allows the definition of thresholds and monitoring intervals, and the interception of network, system, database, and application-messages and alerts. Once a threshold value is exceeded, intelligent agents can run a pre-defined automatic action and/or generate and send a message to alert an operator on a central management console. Messages can also be forwarded to a pager or trouble-ticketing application. To help focus on the most critical problems, a message browser window is used to display six severity levels for incoming problems and events, e.g., ranging from stable to critical. An integrated history database is provided for auditing and analyzing system and network activities, for identifying trends and for anticipating problems before they occur. Activity displays and reports can be customized by the users.
Prior art SNMP network management uses embedded microprocessors in almost every inter-networking device to support two-way inter-computer communications with TCP/IP, of which SNMP is a member of the TCP/IP protocol suite. SNMP is conventionally used to send messages between management client nodes and agent nodes. Management information blocks (MIBs) are used for statistic counters, port status, and other information about routers and other network devices. GET and SET commands are issued from management consoles and operate on particular MIB variables for the equipment nodes. Such commands allow network management functions to be carried out between client equipment nodes and management agent nodes.
SNMP is an application protocol for network management services in the internet protocol suite. SNMP has been adopted by numerous network equipment vendors as their main or secondary management interface. SNMP defines a client/server relationship, wherein the client program, a "network manager", makes virtual connections to a server program, an "SNMP agent", on a remote network device. The data base controlled by the SNMP agent is the SNMP management information base, and is a standard set of statistical and control values. SNMP and private MIBs allow the extension of standard values with values specific to a particular agent. Directives issued by the network manager client to an SNMP agent comprise SNMP variable identifiers, e.g., MIB object identifiers or MIB variables, and instructions to either GET the value for the identifier, or SET the identifier to a new value. Thus private MIB variables allow SNMP agents to be customized for specific devices, e.g., network bridges, gateways, and routers. The definitions of MIB variables being supported by particular agents are located in descriptor files, typically written in abstract syntax notation (ASN.1) format. The definitions are available to network management client programs.
SNMP enjoys widespread popularity, and SNMP agents are available for network devices including computers, bridges, modems, and printers. Such universal support promotes interoperability. The SNMP management protocol is flexible and extensible, SNMP agents can incorporate device specific data. Mechanisms such as ASN.1 files allow the upgrading of network management client programs to interface with special agent capabilities. Thus SNMP can take on numerous jobs specific to device classes such as printers, routers, and bridges. A standard mechanism of network control and monitoring is thus possible.
Unfortunately, SNMP is a complicated protocol to implement, due to complex encoding rules, and it is not a particularly efficient protocol. Bandwidth is often wasted with needless information, such as the SNMP version that is to be transmitted in every SNMP message, and multiple length and data descriptors scattered throughout each message. SNMP variables are identified as byte strings, where each byte corresponds to a particular node in the MIB database. Such identification leads to needlessly large data handles that can consume substantial parts of each SNMP message.
Most vendors implement network managers thinking a user's primary interest is in the data associated with particular network devices. But such data is easily acquired by other means, e.g., "netstat" and "rsh" UNIX programs. The important information about the network includes the differences between devices, besides their current states. SNMP affords a good mechanism for rapidly processing such differences on large networks, since SNMP avoids the processing burden of remote login and execution.
Network management applications can thus monitor the health of every part of a global communications network and can be set to communicate alarms to a central management console. Current network management applications do an adequate job of informing central management consoles about the health of various nodes in the network and the alarms they issue when a node is failing are useful.
Conventional SNMP network management technologies do not provide sufficient information related to the nodes' electrical power status. A new technology is needed that can be simply and inexpensively added to client equipment nodes for SNMP reporting of the electrical power status of the node. For example, in a router based network with SNMP support, prior art individual routers can use SNMP to issue an alarm to the management console. But the console operator would know only that the router is failing. A GET command can be issued to the router node to determine if the counter and buffer thresholds limits were exceeded and caused a router to lock-up. However, the console operator does not have any information about the electrical power status to the router, e.g., has the router power switch been moved to the OFF position or has the switch been accidentally turned OFF? The electrical power source could have failed, the power cable connection become loose, or a technician may have accidentally removed the router from a rack.